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Abstract We describe a software reuse architecture 
supporting component retrieval by facet classes. The 
facets arc organized into a lattice of facet value sets and 
facet n-iupics. The query mechanism supports both pre- 
cise retrieval and flexible browsing. 


1. Introduction 

There are many obstacles in the path to development 
of a practical and useful software reuse environment 
Retrieval of “suitable" reuse candidates from a collection 
of possibly thousands of components is a particularly 
significant obstacle. We describe the design of a compo- 
nent classification scheme and its associated query 
mechanism. The classification scheme is based upon a 
lattice of facet values and facet tuples. The query mecha- 
nism uses type inference rules to locate and retrieve those 
components whose classifications in the lattice arc sub- 
types of the query specification. 

1.1. Software Reuse 

Reuse has long been an accepted principle in many 
scientific disciplines. Engineers make design decisions 
on the availability of components that facilitate product 
development, biologists use established laboratory instru- 
ments and chemists use standardized measuring devices 
to record experimental results. It would be unthinkable 
for an engineer to “design and develop” the transistor 
every time that a transistor is required in an electrical 
instrument. Computer scientists, however, are guilty of a 
comparable practice in their discipline: software reuse is 
not widely practiced in the computer science field. Gen- 
erally, the reasons are: 

1 . Development standards have not been established 

for software: 
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2. There is a pervasive belief that if it is “not developed 
here”, it can’t be used by “us”; 

3. Software is all too often developed with respect to a 
specific requirement with no consideration given to 
reuse in other environments; 

4. Many languages encourage constructs that are not 
conducive to reuse; 

5. Software Engineering principles are not widely prac- 
ticed and consequently, requirements and design 
documents often are not available with the code; and 

6. No widely accepted methodology has been devel- 
oped to facilitate the identification and access of 
reusable components. 

Regardless of the reasons for not developing soft- 
ware for eventual reuse, the spiraling cost of new soft- 
ware development is mandating an increased interest in 
software reuse. It has been estimated that in 1990 alone, 
the output of source code will be 15.3 billion lines of 
code [1 1]. With the minimal effort to reuse existing soft- 
ware, it is natural to ask what percentage of this enor- 
mous number of lines of code will represent duplication 
of effort It has been estimated that only 30 to 40% of 
this code will represent novel applications while 60 to 
70% of the code will apply to generic computer tasks 
such as data entry, storage, sorting, searching, etc. 

Although there are no definitive answers as yet to 
the software reuse problem, there is substantial ongoing 
research on the problem. One area of research is to iden- 
tify characteristics of software components that enhance 
the reuse potential of the component in terms of its bind- 
ings to other modules [3]. Another area of research is to 
identify techniques that can be used to translate a soft- 
ware component that has marginal reuse potential to one 
that can be easily incorporated into a larger system. A 
third research area relative to software reuse that has 
been extensively studied is that of identifying metrics 
that measure software complexity. An example of this is 
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McCabe’s Complexity metric. A very recent area of re- 
search in software reuse is that of the problem of classi- 
fying software in order to identify and access the soft- 
ware [4], [12]. The most promising classification method 
for software reuse is the Faceted Classification System. 
This methodology has been studied extensively by 
Prieto-Diaz and forms the basis for the methodology 
presented in this paper. 

1.2. Faceted Classification 

The faceted classification methodology, as studied 
by Prieto-Diaz, begins by using Domain Analysis “to 
derive faceted classification schemes of domain specific 
objects” [13]. This process relies on a library notion 
known as Literary Warrant. Literary Warrant collects a 
representative sample of titles which are to be classified 
and extracts descriptive terms to serve as a grouping 
mechanism for the titles. From this process, the classifier 
not only derives terms for grouping but also identifies a 
vocabulary that serves as values within the groups. 

From the software perspective, the groupings or fac- 
ets become a taxonomy for the software. Using Literary 
Warrant, Prieto-Diaz has identified six facets that can be 
used as a taxonomy [14]. These facets are: Function, Ob- 
ject, Medium, System Type, Functional Area and Setting. 
Every software component is classified by assigning a 
value for each facet for that component. For example, a 
software component in a Relational Database Manage- 
ment System that parses expressions might be classified 
with the tuple 

(parse, expression, stack, interpreter, DBMS, ). 
Thus, the Function facet value for this component is 
“parse”, the Object facet value is “expression”, etc. Note 
that no value has been assigned for the Setting facet as 
this software component does not seem to have an appro- 
priate value for the Setting facet. 

The software reuser locates software components in 
a faceted reuse system by specifying facet values that are 
descriptive of the software desired. For example, if we 
are using Prieto-Diaz’s facets, suppose that we wish to 
find a software component to format texL We might 
query the system by constructing the tuple 

(format, text, file, file handier, word processor, *). 
Note that the asterisk for the value for the Setting facet 
acts as a wild card in the query which indicates that there 
is no constraint on that facet. If the query results in one 
or more "hits", then the reuser chooses from the hits the 
particular software component that best fits the desired 
need. The problem arises if no hits arc obtained or if the 


software that is identified is not appropriate to the needs 
of the reuser. One solution is to weaken the query by 
relaxing one or more constraints by replacing a facet 
value with a wild card. For.example, if the Functional 
Area facet has the least significance to the required need, 
the reuser could again pose the query with the tuple 
(format, text, file, file handler, \ *). 

This process of weakening the query continues until a 
suitable component is retrieved. 

An alternative method to continue the search after u 
initial query is known as the method of “conceptual 
closeness.” In this method, pairs of facet values for the 
same facet have numeric values associated with them 
that in a sense measures their “degree of sameness." For 
example, the two facet values “delete" and “remove" 
would be very close in meaning and henc.e would have a 
metric value close to 0 indicating their semantic close- 
ness. However, the two values “add” and "format” for 7 
Function have little in common and hence would have a* 
closeness value nearer to 1. In this method, the system 
assumes the responsibility for continued searches by 
modifying the query by replacing facet values with val- 
ues that are “close” in meaning as determined by the 
closeness metric. For example, if the facet value “editor 
is closer to “word processor” in terms of the metric than 
any other value in any facet, then the system poses the 
query with the modified tuple 

(format, text, file, file handler, editor, *) 
and continues in this manner until a hit is obtained. 

Although this appears to be a reasonable solution to 
the problem of continued searches, the difficulty lies in 
the need to assign meaningful closeness values to pairs c 
facet values. With a large collection of values, this is a 
daunting task. However, one solution is suggested by 
adapting the work of Kruskal [8] to the conceptual cIost_ 
ness problem. In this method, a metric is assigned to 
pairs of values based on user acceptance of modified 
queries. The method requires the use of a two dimen- 
sional matrix for each facet indexed by the facet values 
themselves. For example, if an original query tuple con- 
sisting of 

(format, text, file, file handler, word processor, *) 
failed to achieve a hit and the user later accepted a com- 
ponent with the query tuple 1 

(format, text, file, file handler, editor, *), 
the matrix corresponding to the Functional Area facet 
would have one added to the two matrix cells corre- 
sponding to the entries for “word processor” and “edi- 



tor”. Now if N is half of the total of the cell values in the 
matrix, then the distance between “word processor and 
“editor” is defined to be 1 - (cell value)/N where the cell 
value is the value in either of the entries corresponding to 
the pair “word processor” and "editor". It is clear that 
this method requires a large and patient user group in 
order to establish viable metric values. 

1-3. Lattices 

The faceted classification model that we shall de- 
scribe in the next section is based on the mathematical 
notion of a lattice. The definition of a lattice requires the 
concept of a partial ordering on a set. Thus, a partial or- 
dering < on a set A is a relation defined on A that satis- 
fies three conditions, namely: 

a. Reflexive: for all x in A, x < x; 

b. Antisymmetric: for all x, y in A, if x < y and y < x, 
then x = y; 

c. Transitive: for all x, y and z in A, if x < y and y < z, 
then x < z. 

For example, the arithmetic comparison “less than or 
equal” is a partial ordering on the Natural numbers. An- 
other example is the subset relation defined on the power 
set of a set. It should be noted that a partial ordering on a 
set does not guarantee that any two objects in the set can 
be compared using the partial ordering. For example, two 
arbitrary elements in the power set are not comparable in 
the sense that one need be a subset of the other. 

A lattice is a set A on which is defined two binary 
operations, a (meet) and v (join), which satisfy the fol- 
lowing: 

a. Idempotcnt: for any in A, x a x = x and x v x = x; 

b. Commutative: for any x and yinA, XAy = yAX 
and x v y = y v x; 

c. Associative: for any x, y and z in A, x a (y a z) = (x 
a y) a z and x v (y v z) = (x v y) v z; 

d. Absorption Law: for any x and y in A, if x < y, then 
x v y = y and x a y = x. 

Additionally, if for any x, y and z in A, x a (y v z) = 
(x a y) v (x a z) and x v (y a z) = (x v y) a (x v z), we 
say that the lattice is distributive. For example, the power 
set with intersection as the meet and union as the join 
forms a distributive lattice using the subset partial order. 

Let < be a partial ordering on a set A. If X is a subset 
of A, we say that an element a in A is a lower bound of X 
if a < x for every x in X. A Greatest Lower Bound (GLB) 
of X is a lower bound b of X with the property that if a is 
any other lower bound of X, then a < b. It is clear that if a 
GLB exists for a subset X of A, then it must be unique. 


For example, any subset of elements in the power set has 
a GLB consisting of the intersection of all elements in 
the subset In a lattice, any two elements have a GLB 
which is just the meet of the two elements, i.e. if x and y 
are in a lattice A, then x a y < x and x a y < y and if z is 
any lower bound of both x and y, then z < x a y. 

There is a dual to lower bounds which is the notion 
of upper bounds. An clement a is an upper bound for a 
set X if x < a for all x in X. A Least Upper Bound (LUB) 
of a set X is an upper bound b such that if a is any other 
upper bound, then b < a. For the example of the power 
set a LUB for a set X is the union of all the elements in 
the subset In a lattice, any two elements also have a least 
upper bound which is just the join of the two elements. 
Thus, for any two elements x and y in A, x < x v y and y 
< x v y and if z is any upper bound of both x and y , then 
x v y < z. 

We note that if A is a set with a partial ordering < 
such that any two elements have a GLB and a LUB, then 
the set is a lattice where the meet of any two elements is 
the GLB of the elements and the join of any two ele- 
ments is just the LUB of the elements. 

I A Subtvpcs and Inheritance 

The popularity of the Smalltalk programming lan- 
guage [9], with its object orientation and built-in type 
inheritance, has resulted in a flurry of research in object- 
oriented database systems. An object-oriented database 
system is one that is organized around objects and which 
communicates through message-passing. Operations 
(termed methods) arc associated with each object in a 
database; some of these operations are bound to specific 
types of messages for that object. Most message-passing 
systems are not strongly typed, but rather perform run- 
time type checking. This is done primarily to support 
rapid prototyping of applications. Deferring the binding 
of an object or message to a type until run-time reduces 
the amount of effort needed to begin exercising an appli- 
cation, but it also requires a run-time system that can 
handle the errors that may arise. 

The object classes in an object-oriented database are 
organized into a partial ordering. Object classes inherit 
attributes and methods from their ancestors in the order- 
ing. Single inheritance schemes restrict a given object 
class to at most one immediate ancestor in the partial 
ordering. Multiple inheritance schemes allow a given 
object class to have any number of immediate ancestors 
in the partial ordering. Cardclli [5] formalizes some of 
the semantics of multiple inheritance. 
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Object-oriented database systems have a number of 
design goals, some concerning typing, but others con- 
cerning peripheral issues (such as rapid prototyping). 

The type semantics of object-oriented systems (including 
inheritance and subtyping) is present in other systems 
which are not based upon message-passing (e.g., Mor* 
pheus [7], Galileo [2]). Such systems are strongly typed, 
and hence, as Cardelli and Wegner [6] argue, can pro- 
duce more efficient and reliable applications. 

Horn [10] introduces the notion of conformance, 
allowing one type instance to be treated as if it were an 
instance of another type. In a limited sense, this is what 
happens with inheritance, but conformance is more gen- 
eral. Inheritance requires that this treatment only be al- 
lowed when moving up the type hierarchy or lattice. 
Inheritance uses a partial ordering of types (by subtype), 
plus an implicit definition of existence dependencies be- 
tween a given type and its ancestors. Conformance can 
hold for arbitrary types, independent of any type ordering 
scheme. Such a notion is clearly superior to hierarchies 
or lattices for type-related query languages, where inter- 
mediate results (derived from existing types, but not part 
of the database schema) need to be manipulated. 

Inheritance-based systems are, in some sense, navi- 
gational. A user querying an object-oriented database 
must be aware of the inheritance structure of that specific 
database, just as a user querying a network database must 
be aware of database structure. Because of their non- 
navigational characteristics conformance-based models 
promise to gain prominence over inheritance-based mod- 
els, just as relational models have over network models. 


Figure 1 shows the general structure of the reuse 
type lattice. At the top is , the special universal type _ 
Any value conforms to the universal type. At the bottc^; 
is -L , the void type. These two special types ensure that 
any two types in the lattice have a least upper bound aril 
a greatest lower bound, respectively. Between the uni -~, 
vcrsal and void types appear the upper and lower bounds 
for the two type constructors facet and tuple. Faceto a* 
characterizes the notion of the empty facet type; it con— 
tains no values, but is still a facet. Likewise, Facet char- 
acterizes the notion of the set of all possible facet value"" 
The doited line between them indicates that an arbitrary^ 
number of types may appear here in the lattice. For ex- 
ample, figure 2 shows the sublattice for facet sets for ti 
examples in section 1.2. W 

The tuple sublattice has a similar structure. At the 
top is the empty tuple type ( ) , characterizing a tuple w'El 
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Figure 1. The reuse type Lattice 
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no facets. At the bottom is tuple, the tuple type with ail 
possible facets. 

2J. .-Facets VS. Facet Value .Sets 

Traditional retrieval of individual facet values relies 
upon maximal conjunction of boolean terms for retrieval 
of matches on all facets and maximal disjunction of 
boolean terms for matches on any facet of an expression. 
In order to fit the notion of facet into the type lattice, we 
look at sets of facets. A set of facets corresponds to a 
conjunction on all of the facets comprising the set Each 
set occupies a unique position in the type lattice. We 
handle disjunction by allowing a given component to 
occupy multiple lattice positions. Matching occurs on 
any of the positions, providing the same semantics as 
disjunction. 

Facet values are equivalent to enumeration values. 
We attach no particular connotation within the type sys- 
tem to a particular facet value. Values are bound to some 
semantic concept in the problem domain. 

The subset relation is our partial order. The least 
value of this portion of the lattice is the set of all facet 
values from all facets in the problem domain, denoted by 
the distinguished name Facet. The greatest value of this 
portion of the lattice is the empty set, denoted by the dis- 
tinguished name Faceto. The union operator generates 
the greatest lower bound. The intersection operator gen- 
erates the least upper bound. 

2. Type Inference Rules 

We begin with a brief remark concerning notation. 

In the inference rules that follow, the symbol A repre- 
sents an existing set of assumptions. A always contains 
the type information generated by the database schema 
which implements the repository. It is occasionally nec- 
essary to extend the set of assumptions with some addi- 
tional information. A.x denotes the set of assumptions 
extended with the fact x. A ** x states that given a set of 
assumptions A, x can be inferred. Inferences above the 
horizontal line act as premises for the conclusions, the 
inferences below the horizontal line. An expression is 
well-typed if a type for the expression can be deduced 
using the available inference rules, otherwise it is ill- 
typed. 

3.1 . Domain Interval Subtvping 

We adapt the notion of a domain interval [7] to for- 
malize our notion of facet value sets. In [7] a subtype 
was smaller than its supertype; here die reverse is true, a 
subtype is a larger collection of values than its supertype. 


A domain interval is a type qualification that explic- 
itly denotes the valid subrange(s) for a base type. As- 
sume that t is a base type ordered by < (the ordering may 
be arbitrary). A domain that is (inclusively) delimited by 
two values, a and b, is denoted t<»...b). A non-inclusive 
lower bound is denoted a* and a non-inclusive upper 
bound is denoted by b*. Intervals made up of more than a 
single continuous value range are denoted by a set of 
ranges, for example, u....b, ,...* «> denotes the interval that 
includes the subinterval a through b inclusive, the subin- 
terval c through d inclusive, and the singleton value e. 
The singleton range e is equivalent to e. . .e. When we 
use such notation we intend that a < b and c < d, but not 
necessarily that b < c or d £ e. An empty pair of brack- 
ets, to, denotes an empty interval, i.e., one which con- 
tains no elements. In our particular application, the base 
types are finite sets of enumeration (facet) values. 

Premises concerning membership of interval bound- 
ary values (c.g., m and n in (1.1) and (1.2)) are assumed 
to be part of the assumptions, and will not be explicitly 
mentioned after this. Rule (1.1) provides for subtyping a 
Al-met 
A h n e t 

Ah m< n (1.1) 

A h t < t< m ... n) 

subrange of some type t; (1.2) does the same for two sub- 
Ahmet 
A h m' e t 
A h n e t 

Ahn'et (1.2) 

Aim' < m <n < n' 

A h t( m '_ .j,') < 

ranges of some type t. Rule (1.3) extends subtyping to 
A h t(mi...m) i t(m l '..4i|') 

A h tfa „ (1-3) 

A h t( m| ... n t( m |\,ji,' r ..,rn,'..jj/) 

domain intervals, where each subinterval in the subtype 
is a subtype of some interval in the supertype. 

The following rules are used to combine ranges in 
domain intervals. In rule (1.4), two ranges in an interval 
A h x . t{„ t)L ^ b...c,...) 

Ahx:t < ..., a .„ c> ... > (1.4) 

that share a common endpoint can be combined into a 
single range. This 4can also be done when one end point 
is inclusive and the other is exclusive (rules (1.5) and 
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(1.6)). Overlapping ranges arc merged into a single 
A ^ X • a... b*, b...c,...) 


AFx :t(,..a... c ....) 

A x • a...U b*...c,...) 


(1.5) 


( 1 . 6 ) 


A x • t(.... a...c, ...) 
range that uses the minimum of the two lower bounds as 


the new lower bound and the maximum of the two upper 
bounds as the new upper bound in rules (L7) and (1.8). 
A H X : h..d, ...) 

AHa<b^c<d 

AH x:t(..., a ..d,...) 

A H X*. h..c, ...) 

A H t(a...d) < 

AH x: a...d t ...) 

The next two inference rules deal with unary domain 
values. And the last two deal with complete intervals. 


A H x : t(. 

-a,...) 


A H x : 

a.. .a, ...) 

(1.9) 

A H x : t(..„ 

a.. .a, ...) 

(1.10) 

A H x : t(. 

..a,...) 

A H X 

; t 


A H x : t<. 

00... op) 

(1.11) 


(1.12) 

AH x 

:t 


In order to establish the type of the result of an op- 
eration such as union, some notion of domain interval 
union is needed. If M and N arc two intervals over the 


(1.7) 

( 1 . 8 ) 


same type, then M u N is constructed by merging the 
two sets of ranges making up the intervals, and using the 
domain inference rules described above to reduce the 
result 

A l- x : t^MuN) 

AI-x:t<M.N> (1 -13) 

In a similar fashion, for two intervals M and N over 
the same type, their intersection, M n N, can be con- 
structed by selecting only those ranges which are com- 
mon to both domain intervals. The domain inference 
rules arc used to decompose the given ranges into sets of 
disjoint ranges and common ranges. The set of common 

ranges makes up the intersection interval. 

A H rn b < n a 

A H l((m,...mt,)n (n,..ji b ), = 1<M) 0-14) 

A H m a < n a < m b < n b 

A ^ ^((nv ...ms) r» (n,...nb),M) = t((n, .. jn.),M) 0-15) 


A I- m a < n a < n b < m b *■ 

T~T t (1.16) 

2.2. Tuple-. Sub tvping W 

This collection of inference rules explicitly types the 
tuples that classify components. We view a tuple r to t _ 

of type record, {t, t.) . The type ^ must be a facet ® 

type. The empty tuple (i.e., the tuple containing no fac- _ 
els) is of type {), the tuple type with no components. 

The order in which types appear is not arbitrary, since m 
position is used to distinguish facets. 

Inference rules (2.1) and (2.2) allow for the defini-“ 
tion of a tuple and the extraction of an attribute from a 
tuple. If ei through e. arc type expressions of type ti 

A h ej= ar 

A H e n = t n dU 

A-(r — (ej, ..., e n )) hr. { t j, . . . , t n } • 


through to respectively, then the tuple constructed from 
them will be of the type resulting from the record con- « 
structor ‘ [ ) ’ applied to those types. We use type expres- 
sions to allow construction of attribute types without 

requiring the earlier definition of all the types needed, mg 
Note that the same syntax is used to denote both the defi- 
nition of the tuple and its type. If attribute i in tuple r is 
of type t then the result type for the component extract^ 
r.i is L 


A h r : { 1 1 . . . tn } 
A h 1 < i < n 
A h r.i : t 


(2.2T. 


New tuple types are constructed from existing tuple~ 
types using the tuple constructor which accepts two”’ 
tuple types and returns a tuple type containing all comp - ' . 
nents of both argument types. fE 


A h Tj . { t j, ■ - - , t m } = 

A h T 2 . {tmfi, t u ) 

AH 1 < m < n (2.3J^ 

A H Tj & T 2 = {t 1 , — , t n } — 

Rules (2.1) and (2.2) give the type semantics for 
construction of tuples from attributes and for extraction “ 
of an attribute from a tuple. Rule (2.4) characterizes th^ 
notion of subtype between two tuples: One tuple is a 
subtype of another if it has all of the attributes of the — ' 
other (attributes common to both tuple types must be of 
the same type in both tuple types), and possibly some 
additional attributes. This may seem contrary to the in- ~ 
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A I- ti 
A H t m 

A U M 

A t- t n 

A I- 1 < m < n 

A H {ti, , tm, ... ,t n } i { 1 ... , t m } 

tuilivc notion of subtype being a restriction of a type. 
Consider, however, that an instance of a subtype must be 
able to be used as an instance of its supertype, and thus 
must contain all of the supertype's attributes. 

Rule (2.5) extends record subtyping to handle the 
A f- 1 <m < n 
A h t'i<t! 


A H t' m < t 


m - 1 m 


A !■ {t 1, ..., t m , ..., t n } i { t j. 



situation where a component of the subtype is a subtype 
of the corresponding component in the supertype. Infer- 
ence rule (2.4) required that the corresponding attributes 
be of the same type. Rule (2.5) generalizes (2.4) by deal- 
ing with subtyping of the attributes in addition to the re- 
spective record types. 


4. Ouerviny the Repository 

The repository is partitioned by structural similarity 
(package, function, etc.). Each partition is associated 
with a set of facets which characterize and classify the 
members of the partition. The particular facets and the 
number of facets associated with a partition varies as 
needed to adequately characterize it. A given facet may 
be unique to a partition, or it may be shared by many 
partitions. The function facet from section 1.2. is a good 
example of a facet likely to be shared by a majority of 
partitions in the repository. 

Each partition instance has one or more lattice verti- 
ces that correspond to the sets of section 2.1. There is 
always the primary lattice vertex corresponding to the 
tuple of facet value sets characterizing this component as 
a member of the partition. Additionally, there may be 
zero or more secondary lattice vertices corresponding to 
alternative characterizations of the component or charac- 
terizations of subcomponents contained within this com- 
ponent 

4.1. Repository Structure 

Two persistent storage areas comprise the actual 
repository: a set of text files, and a set of database rela- 
tions. The text files contain the body of the components 


themselves, or descriptions of them (in the case of a 
commercial product described in a local repository). The 
database relations store the lattice vertices. 

Each database relation corresponds to the lattice ver- 
tex characterizing a particular repository partition. The 
type of the relation is then the type of the partition, which 
is the least upper bound of all the tuple types of the com- 
ponent vertices comprising the partition. Efficient algo- 
rithms for lattice operations such as LUB are described 
in [1]. 

There is also a relation made up of facet value/syno- 
nym pairs. This relation is described in section 4.2. Ad- 
ditional relations may also be present if there are alterna- 
tive characterizations or subcomponents characteriza- 
tions not equivalent to some primary partition characteri- 
zation. 

4.2. Quer y Evaluation 

A query is a boolean expression containing predi- 
cates and the operators and, or, and not. A predicate is 
simply a constant of type tuple. When a user issues a 
query, the query evaluator first treats all of the facet val- 
ues in the query as synonyms and replaces them with 
actual facet values from the value/synonym relation. For 
example, “database,” “databases,” “data base,” and “data 
bases" might all be replaced with “database.” The evalu- 
ator then locates all of the relations in the database whose 
type conforms to some predicate of the query using the 
inference rules of section 3. Specific tuples which con- 
form to some predicate are then retrieved from the con- 
forming relations (once more using the inference rules). 
The result is then a set of component references, which 
can be optionally retrieved from the text storage area. 

4J, Browsing as Retrieva l of Subtypes 

Treating a query as an editable entity in the user in- 
terface provides a straightforward browsing tool. For 
example, attaching facets to a query comprised of a sin- 
gle tuple makes the query less general. Fewer and fewer 
partitions conform to the tuple type. Specifying exactly 
those facets found in a given partition restricts retrieval 
to only that partition. Over— qualification results in 
empty retrieval. 

Removing facets from the query tuple makes the 
query in turn more general. Specifying an empty tuple 
results in all partitions of the repository conforming to 
the type of the query tuple (all record types arc subtypes 
of the empty record { ) ). 
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5. Conclusions 

The reuse architecture described here uses the 
proven method of faceted classification as a starting 
point for a retrieval mechanism providing both precise 
characterization of components and flexible specification 
of queries. Its simple user interface encapsulates a data 
model founded in formal lattice and type theory. 
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